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= Software  E n g i nee ri ng  In sti tute 

The  Key  Question 


Requirements  Software  Architectures 


How  do  we  systematically  move  from  a  set  of 
requirements  to  a  software  architecture  that 
satisfies  those  requirements? 
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The  Problem 

Designing  is  very  knowledge  intensive: 

•  The  required  expertise  rarely  resides  in  one 
place/person 

•  It’s  unclear  how/what  knowledge  should  drive  design 

Knowledge  requirements: 

•  Domain 

•  Quality  attribute  (e.g.  performance,  security, 
modifiability) 

•  Architectural  design 

•  Design  methodology 
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Software  E n g i nee ri ng  In sti tute 

Our  Goals 

Goal:  To  methodically  design  software 
architectures  so  that  they  predictably  meet 
quality  attribute  requirements. 

Sub-goals: 

•  Determine/discover  fundamental  design 
principles 

•Operationalize  principles  via  method(s) 
(“Attribute  Driven  Design”) 

•  Investigate  techniques  and  build  prototypes 
for  automated  support  (ArchE) 
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Types  of  Requirements 


Requirements  Software  Architectures 

Constraints  -  pre-specified  design  decisions 

Features  -  what  functions  add  value  to  the  user  (e.g.  what  the  system 
does) 

Quality  Attribute-  how  well  the  system  does  by  various  measures  (e.g., 
how  timely,  secure,  modifiable  it  is) 
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What  type  of  requirements  drive 
architectural  design? 

Answer:  Functional  requirements  are  least  important  for 
architecture  design  -  quality  requirements  and  constraints  are 
most  important 

Here’s  some  evidence: 

If  the  only  concern  is  functionality  then  a  monolithic  system 
would  suffice. 

However  is  it  quite  common  to  see: 

•  Redundancy  structures  for  reliability 

•  Concurrency  structures  for  performance 

•  Layers  for  modifiability 
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Software  Engineering  Institute 

What  does  an  architect/ArchE  need 
to  know  to  methodically  design? 

Knowledge  requirements 

•  Quality  knowledge  -  how  to  achieve  required  qualities  in 
an  architecture  design 

•  Architecture  design  process  -  how  to  get  an  architecture 
from  requirements 

Our  approach: 

•  Precisely  define  quality  attribute  requirements  in  terms  of 
scenarios. 

•  Exploit  the  “structure”  of  quality  attribute  models  to  define 
the  structure  of  well-formed  architectures. 

•  Define  transformations  between  architecture  models, 
quality  attribute  models,  quality  attribute  scenarios  and 
quality  attribute  measures. 
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We  have  a  common  form  for  specification  of 
quality  requirements 

We  use  quality  attribute  general  scenarios,  which  are 
system  independent,  to  guide  the  specification  of  quality 
attribute  requirements. 

We  characterize  quality  attribute  requirements  for  a 
specific  system  by  a  collection  of  concrete  quality 
attribute  scenarios.  These  are  instances  of  general 
scenarios. 

We  use  general  scenario  generation  tables  to  construct 
well-formed  general  scenarios  for  each  attribute. 


©  2005  by  Carnegie  Mellon  University  Version  1.0  page  10 


5 


©  2005  by  Carnegie  Mellon  University 


Carnegie  Mel  Ion 

Software  Engineering  Institute 


—  ( ’an  Mfric  ^  1H  Ic  h  i 

-  _  Software  Engineering  Institute 

General  Scenarios 

General  scenarios  have  six  parts.  The  “values”  for  each 
part  define  a  vocabulary  for  articulating  quality  attribute 
requirements.  The  parts  are: 

•  Stimulus 

•  Source  of  stimulus 

•  Environment  in  which  the  stimulus  arrives 

•  Artifact  influenced  by  the  stimulus 

•  Response  of  the  system  to  the  stimulus 

•  Response  measures 
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Availability  Scenario  Generation  Table 

Source  of  stimulus: 

Stimulus: 

•  Internal  to  the  system 

S  Unanticipated  event 

S  External  to  the  system 

•  Update  to  a  data  store 

Environment: 

Artifact: 

S  Normal  operation 

s  Process 

•  Degraded  mode 

•  Persistent  storage 

Response: 

Response  measures: 

S  record  it 

S  Availability  percentage 

S  notify  parties 

•  Time  range  in  which  the 

S  operate  in  normal  or 

system  can  be  in  degraded 

degraded  mode 

mode 

Example  Scenario: 

“An  unanticipated  message  is  received  by  a  system  process  during 

normal  operation.  The  process  has  to  record  it,  inform  the 

appropriate  parties  and  continue  to  operate  in  normal  mode  without 

any  downtime.  ’’ 
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What  does  it  mean  to  satisfy  a  quality 
attribute  requirement? 


A  quality  attribute  requirement 
defines  a  region  within  the  sei 
quality  attribute  measures. 

An  architecture  can  be  interpreted  in 
terms  of  quality  attribute  model 
which,  in  turn,  can  be  evaluated  to 
determine  which  quality  attribute 
value  the  software  architecture  will 
achieve  for  a  particular  stimulus. 
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Quality  Attribute  Models 


PerfRqt 


Quality  Attribute  Requirements 

Scenario  includes: 
•Stimulus  (arrival  rate)- 
•Response  (Latency)7 


Quality  Attribute  Models 

^Latency  =  F( 
-►Arrival  rate, 


Software  Architectures 

Bound  by 
scenario 


©2005  by  Carnegie  Mellon  University 


Computational  requirements^  Bound  by 

Priorities  of  tasks,  Architecture 

)  I  or  constraints 

A  A  A  A 


7 


©  2005  by  Carnegie  Mellon  University 


Carnegie  Mel  Ion 

Software  Engineering  Institute 


-  CtimrgirMHIiHi 
Software  Engineering  Institute 

Parameters  define  architectural  tactics 


Scenario  includes: 
•Stimulus  (arrival 
•Latent 


Latency  =  F( 

Arrival  rate, 

Computational  requirements^ 
Priorities  of  tasks, 


Bound  by 
scenario 


Bound  by 

architecture 

or 

constraints. 


Tactics  are  designed  to  adjust  the  parameters. 

Can  work  backwards  -  determine  which  values  of  parameters 
will  satisfy  latency,  with  given  arrival  rate,  and  then  ask  whether 
these  values  are  architecturally  achievable  using  tactics. 

May  also  weaken  constraints  or  requirements  using  tactics. 
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What  are  architectural  tactics? 


For  the  six  quality  attributes  -availability, 
modifiability,  performance,  security,  testability, 
usability  -  we  have  enumerated  a  collection  of 
“tactics” 

Formal  definition:  An  architectural  tactic  is  a 
means  of  satisfying  a  quality  attribute 
response  measure  by  manipulating  some 
aspect  of  a  quality  attribute  model  through 
architectural  design  decisions. 
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Architectural  Tactics 


Quality  Attribute  Measures 
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Events 

arrive 
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\ 

Performance 

Performance 

Resource 

Resource 

Demand 

Management 

Arbitration 

\ 

\ 

\ 

•  Increase 

•  Introduce 

•  Scheduling 

Computational 

Concurrency 

Policy 

Efficiency 

•  Maintain  Multiple 

•  Synchronization 

•  Reduce 

Copies 

policy 

Computational 

•  Increase 

Overhead 

Available 

•  Manage  Event  Rate 

Resources 

•  Control  Frequency 

V. 

of  Sampling 

Response 
generated 
within  time 
constraints 
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ArchE  -  Architectural  Expert 

ArchE  is  a  tool  intended  to  complement  an  architect  during 
the  design  process 

Our  vision  is  that 

•  The  architect  has  domain  knowledge  and  an 
understanding  of  what  is  feasible 

•  ArchE  has  knowledge  of  quality  attributes  and  their 
relation  to  design 

ArchE  is  emerging  work  at  the  SEI. 
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ArchE  vis  a  vis  any  particular  quality 
attribute 

Quality  attribute  theories  are  created  and  change  over 
time 

We  want  ArchE  infrastructure  to  be  independent  of  any 
particular  quality  attribute 

•  ArchE  is  modular  with  respect  to  quality  attributes  that 
are  included 

•  We  use  term  “reasoning  framework”  to  describe  how 
quality  attribute  knowledge  is  encapsulated  in  ArchE. 

•  We  view  reasoning  frameworks  as  “plug-ins” 
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Process  of  using  ArchE  (current 
version) 

Architect:  provide  scenarios  and  features  to  ArchE 

ArchE:  generates  initial  architecture  based  on  reasoning 
frameworks  and  scenarios 

ArchE:  presents  list  of  possible  tactics  to  improve 
architecture  to  architect 

Architect:  choose  tactic  to  apply 

ArchE:  apply  tactic  and  generate  new  list  of  possible 
tactics 
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ArchE  Uses  Tactics  to  Move 
Architecture  in  the  Design  Space 


Quality  Attribute  Requirements 


Models 


Software  Architectures 


An  architectural  tactic  moves  from 
one  architecture  to  another  where 
a  parameter  of  the  quality  attribute 
model  moves  in  a  known  direction. 


Quality  Attribute  Measures 
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Initial  Functions  for  Sensor  Demo 


Correct  for 

environmental  Identify  differences 
factors  from  Past  readings 


Determine 
sensor  status 


Key: 

(7T)  Responsibility 

Data  flow 

Sensor  input  goes  down  two  baths 

One  determines  whether  sensor^s 
operational  \ 

One  calculates  values  and 
potential  alerts  based  on  values 
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Functions  as  they  are  entered  into 
ArchE 

1 .  Receive  data  from  sensor  (Receive) 

2.  Correct  for  environmental  factors  (Correct) 

3.  Determine  sensor  status  (Status) 

4.  Identify  warning  conditions  (Detect) 

4.1  Identify  differences  from  past  readings  (Diff) 

4.2  Determine  warning  status 

4.2.1  Determine  warning  status  of  type  1  (Type  1) 

4.2.2  Determine  warning  status  of  type  2  (Type  2) 

5.  Inform  rest  of  the  system  of  any  errors  (Inform) 

(Demo  step  1) 
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Scenarios  for  the  Sample  Problem 

Modifiability 

1 .  Replace  sensor  without  change  to  functionality  within  4 
person  days 

2.  Add  new  warning  status  without  impacting  existing  warning 
statuses  within  2.5  person  days 

Performance 

1 .  Determine  sensor  status  within  250  ms  after  receiving  sensor 
input.  Sensor  input  arrives  every  500ms 

2.  Determine  differences  from  past  readings  within  1250ms 
after  receiving  input.  Input  arrives  every  1600ms. 

3.  Inform  the  rest  of  system  of  any  alerts  within  350ms  after  the 
arrival  of  alert  status.  Alert  status  arrives  every  350ms. 

(Demo  step  2) 
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Relate  Scenarios  to  Responsibilities 

Responsibilities  and  relations  among  responsibilities  carry 
parameters. 

Scenarios  are  not  yet  related  to  responsibilities. 

Costs,  execution  times,  and  dependency  are  not  yet 
assigned 

Thus,  there  is  not  enough  information  for  ArchE  to 
determine  whether  the  scenarios  can  be  met. 
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Initial  Architecture  for  Impact  Analysis 

If  no  assignment  of  responsibilities  to  modules  then  assign 
each  responsibility  from  initial  set  to  its  own  module. 

(Demo  step  3) 

Retrieve  parameters  from  architect. 

•  Cost  of  change  of  responsibility 

•  Probability  of  change  propagating 
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Parameterized  Values  of  Impact 
Analysis  Model 

Receive  data 

from  sensor  Inform  rest  of 


of  type  2 
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Scenarios  for  the  Sample  Problem 

Modifiability 

1 .  Replace  sensor  without  change  to  functionality  within  4 
person  days 

2.  Add  new  warning  status  without  impacting  existing  warning 
statuses  within  2.5  person  days 

Performance 

1 .  Determine  sensor  status  within  250  ms  after  receiving  sensor 
input.  Sensor  input  arrives  every  500ms 

2.  Determine  differences  from  past  readings  within  1250ms 
after  receiving  input.  Input  arrives  every  1250ms. 

3.  Inform  the  rest  of  system  of  any  alerts  within  350ms  after  the 
arrival  of  alert  status.  Alert  status  arrives  every  350ms. 
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ArchE  Proposes  Possible  Tactics 

For  modifiability  ArchE  can  propose  tactics  like: 

•  Localization 

•  Encapsulation 

•  wrappers 

We  choose  “localize” 
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Result  after  tactic  “localize” 


Receive  input 

from  sensor  Inform  rest  of 
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Result  after  changing  dependencies 
and  choosing  encapsulation 


Smooth  input 


Inform  rest  of 
system  of  any 
alerts 


Key: 

Responsibility  with 
cost  factor 
Dependency  with 
n  probability 


3.97  D< 
Scenario 
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Scenarios  for  the  Sample  Problem 

Modifiability 

1 .  Replace  sensor  without  change  to  functionality  within  3 
person  days 

2.  Add  new  warning  status  without  impacting  existing  warning 
statuses  within  2  person  days 

Performance 

1.  Determine  sensor  status  within  250  ms  after  receiving 
sensor  input.  Sensor  input  arrives  every  500ms 

2.  Determine  differences  from  past  readings  within  1250ms 
after  receiving  input.  Input  arrives  every  1600ms. 

3.  Inform  the  rest  of  system  of  any  alerts  within  350ms  after 
the  arrival  of  alert  status.  Alert  status  arrives  every 
350ms. 
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(2)Responsibility 
(n  is  exec  time) 


affects 


0 


Task 


\JJ 


Latency  =  INF  ! 


Total  utilization  >  1 .0  and  deadlines  are  violated  ! 
Tactic:  Try  reducing  execution  times  of  several 

responsibilities (Demo  step  6) 
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(©Responsibility  ,►  affects  I  1 
(n  is  exec  time)  /  /  Task 


Scenario  1  - 

Period  (500)  and  Deadline  (250) 


Status 


120 


Latency  =130 


m 


Scenario  2  - 

Period  (350)  and  Deadline  (350) 


(225^ 

Inform 


Latency  =  360  ! 

m 


Scenario  3  - 

Period  (1600)  and  Deadline  (1250) 


(ST)  (ST) 

Receive  Correct  Detect 


Latency  =  2375  ! 


Total  utilization  <  1.0  but  deadlines  are  still  violated  ! 
Tactic:  Try  reducing  execution  time  of  Status. 
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(^Responsibility 
(n  is  exec  time) 


affects 


0 


Task 


\JJ 


Scenario  1  - 

Period  (500)  and  Deadline  (250) 


Status 


Latency  =120 

tn 


Scenario  2  -^>r385 

Period  (350)  and  Deadline  (350) 


Inform 


Latency  =  345 


Scenario  3  - 

Period  (1600)  and  Deadline  (1250) 


(5)  (ST) 

Receive  Correct  Detect 


Latency  =  1980  ! 


One  deadline  is  still  violated  ! 

Tactic:  Try  increasing  period  of  Inform. 


(Demo  step  8) 
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(©Responsibility  ,►  affects  I  1 
(n  is  exec  time)  /  /  Task 


Scenario  1  - 


.550 


Period  (500)  and  Deadline  (250) 


(120, 

Status 


Scenario  2  - 

Period  (385)  and  Deadline  (350) 


(225^ 

Inform 


Latency  =120 

m 


Latency  =  345 

m 


Scenario  3  - 

Period  (1600)  and  Deadline  (1250) 


\30^)  (ST)  (ST) 

Receive  Correct  Detect 


Latency  =  1410  ! 

One  deadline  is  still  violated  ! 

Tactic:  Try  increasing  period  of  Status. 
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(2)Responsibility 
(n  is  exec  time) 


affects 


0 


Task 


\JJ 


(Demo  step  8) 
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- 1_  Software  Eng  ineeri  ng  In  sti  tute 

Status 

Applying  ArchE  to  realistic  examples 

•  ArchE  has  demonstrated  that  methodical  design  with 
predictable  results  is  possible  for  small  systems. 

•  We  are  looking  for  collaborators  to  help  us  with  the 
extension  of  PAD  and  ArchE. 

Extensions  to  ArchE  that  are  underway 

•  Input  constraints 

•  ArchE  proposes  patterns  as  well  as  tactics 

•  Variability  reasoning  framework 

•  Extension  of  performance  reasoning  framework 
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Future  Work  - 1 

Make  searching  more  efficient 

•  Patterns  presented  to  architect  as  well  as 
tactics 

•  Tradeoffs  managed  in  a  better  fashion 

•  Better  initial  guess  at  architecture 

•  More  sophisticated  search 

•  Learning  based  on  past  choices 
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Future  Work  -  2 

Make  more  and  better  reasoning  frameworks 

•  More  depth  in  current  reasoning  frameworks 

•  Add  reasoning  frameworks  for  other  attributes  (e.g., 
variability,  security,  dependability) 

•  Develop  domain  specific  language  for  specification  of 
reasoning  frameworks 

•  Make  ArchE  more  realistic 

-  Apply  to  more  sophisticated  problems 

-  Improve  the  user  interface 
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More  Information 

Three  SEI  technical  reports  available  on  our  web  site: 

1.  Illuminating  the  fundamental  contributors  to  software 
architecture  quality.  CMU/SEI-2002-TR-025 

2.  Deriving  architectural  tactics:  A  step  toward  methodical 
architectural  design  CMU/SEI-2003-TR-004 

3.  Preliminary  Design  of  Arch  E:  A  Software  Architecture 
Design  Assistant  CMU/SEI-2003-TR-021 

Lists  of  general  scenarios  and  tactics 
are  available  in  second  edition  of 
Software  Architecture  in  Practice 
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